Intro to NGINX
If you’ve been following along with my posts, you have a sound introduction to Apache Web Server, how it functions, it’s place in history, and how Sumo Logic can help you sort through the numerous logs provided. Apache Access and Error logs are integral to understanding the traffic patterns and issues your users face when accessing your web applications. Sumo Logic helps administrators parse through logs, isolate issues, and determine the root causes of errors. Sumo Logic also provides invaluable insight for business and product development teams in order to gauge user interaction and navigation patterns.
Today we will be covering NGINX, an open source software web server and main alternative/competitor to Apache HTTP Server. NGINX has been gaining in popularity since its inception and is used across a wide spectrum of applications for web serving, reverse proxying, caching, load balancing, media streaming, and much more.
Quick History of NGINX
In 2002, web developers across the internet were tasked to tackle the challenge of engineering a web server capable of handling ten thousand concurrent web connections, as what would be considered a required benchmark of the modern web. Igor Sysoev, a Russian software engineer released the first public version of NGINX. The challenge was met by relying on an asynchronous, event-driven architecture. This means that unlike Apache HTTP Server, NGINX handles multiple processes and threads for requests in one worker process, as opposed to dedicated processes or threads, which Apache is known for.
NGINX vs Apache
There was a time when Apache reigned supreme without question and everyone was a long way back. Today, in 2019, the web server landscape has changed and depending on who you source, NGINX and Microsoft’s IIS are neck and neck for 2nd place, or could be swapped for 2nd or 3rd place depending on the specific function of your server. Either way, Apache is losing ground quickly as web applications and their functions are becoming more dynamic and specific to their cause. A decade ago, when web applications and servers were nearly all the same, Apache could handle almost everything you needed, but as the web grew and different needs were required, NGINX began to fill a need that Apache couldn’t. Apache is great for shared hosting of multiple sites, but NGINX is showing it’s strength and dominance for dynamic content, elaborate features, and pure flexibility in an ever-changing landscape of web content.
Just like Apache and the LAMP stack, NGINX has become popular by offering itself as a LEMP solution for software developers (with the E being used as the phonetic spelling of NGINX). Linux, NGINX, MySQL, and PHP/Python has become a very popular stack that mirrors the classic web LAMP stack. While Apache and the LAMP stack is still a very popular solution, and depending on your use case, you may want to consider NGINX and LEMP as your next go-to stack for your web application.
How is NGINX Different than Apache?
NGINX came into the server landscape after Apache, therefore its developers were more aware of the issues and technical limitations plaguing Apache. As previously mentioned, NGINX relies on event-driven, asynchronous, single-threaded architecture. By utilizing the underlying power of modern operating systems like Linux and Unix, NGINX is able to serve at least 10x more (and often 100–1000x more) requests per server compared to Apache. Efficiently optimizing the use of memory and CPU, NGINX is capable of rapidly scaling to provide more users connections while also providing better bandwidth, all while being less of a resource hog when compared to other modern operating systems.
NGINX handles requests differently than Apache which makes NGINX suitable for a more dynamic environment with varied roles. Some of the most popular use case scenarios for NGINX to be used in a web application besides serving dynamic web content include: Having NGINX in your stack allows developers the capability to use it as a reverse proxy server for HTTPS and other TCP protocols, load balancing for efficient traffic distribution, and HTTP caching.
While it’s totally doable for Apache to be used as a load balancer, Apache is known more for its power and durability while NGINX is known for speed, responsiveness, and resource efficiency. Therefore it’s much more common to have NGINX as a reverse proxy with Apache as the back end server.
How Does NGINX Process Dynamic Requests?
You can run benchmark tests all day but real world use-cases are a much better way to determine how servers behave in the wild. We can take a look at static vs dynamic content and how each server handles both requests.
Apache — Part of what makes Apache great is its modular configurability with MPMs, or “multi-processing modules” Apache is fully capable of handling static and dynamic content through conventional file-based methods and also through it’s MPM workers. By embedding a required language processor within each worker instance, Apache can server PHP, Python, and other popular languages for dynamic content.
Being able to handle dynamic content internally without passing to external processes allows Apache to serve it’s content rather simply.
NGINX — On its own, NGINX is not capable of processing dynamic content natively. In order to handle a scripting language such as PHP, NGINX must pass the request to an external processor that handles the execution of the script and then it waits for the content to be sent back, rendered and ready to be served to the end user. While it sounds complicated and more complex than Apache, there are some advantages.
NGINX uses protocols such as http, FastCGI, SCGI, uWSGI. Since the dynamic interpreters are external and not integrated with the worker processes, the overall overhead is reduced which inturn gives NGINX its reputation of speed and responsiveness.
Conclusion
In this intro to NGINX, we covered a brief history of the NGINX server, how it came to be, its place within the server landscape and also the benefits of NGINX over Apache. While both types of servers are leaders and powerful within their own right, it’s important to recognize specific use-case scenarios so developers and administrators can be better equipped when it comes to making infrastructure decisions.
In Part 2 of Introduction to NGINX, we’ll be taking a deeper dive into NGINX including configuration management, log files, error pages, and the different types of modules that can be used to enhance your web application and server architecture. Stay tuned for Part 2 soon.